What's the reasoning for:

1. Putting this on FluidDataStoreContext instead of ContainerRuntime, given that ContainerRuntime currently has the async createDataStore?
2. Requiring it to be a child?

Only the context has access to its factory synchronously, as its factory must be loaded before it is realized. This is basically the same pattern we use for dds.

EDIT: I meant to put this comment in dataStoreFactory.ts, oops :)

I don't think I understand what the motivating scenario is for this PR, so I'd love to learn more about that. This comment is purely taking this PR at face value, so if I'm missing some special context let me know.

At a very high level, I'd question whether a sync factory pattern is moving in a good direction for our overall instantiation flows.

One pain point of Aqueduct (and therefore almost all of our current data store examples) is that the async startup flows are deferred to the data store instance (i.e. async initializingFirstTime, async hasInitialized). This leaves the instance in a prolonged "half-initialized" state which is prone to errors that don't account for certain invariants being violated.

Fluid basically mandates async somewhere in the construction flow though, due to retrieving handles, getChannel, etc.), so we can't go fully sync all the way to full initialization for most scenarios.

An alternative approach (ditching Aqueduct) would be to embrace an async factory, and move all async initialization up to the factory such that by the time we call the instance constructor, we are ready to be fully sync (and the instance is fully initialized in the constructor).

I've explored this pattern in https://github.com/microsoft/FluidFramework/blob/main/examples/utils/migration-tools/src/migrationTool.ts if you'd like an example. Fully admit there's some personal preference here, but I think this aligns better with DI principles, simplifies the instance class, and strengthens the instance class's invariants.

scriptor has a case where they want to create a child datastore in response to user input, so there is no opportunity to do async actions.

i'd not confuse this with all instantiation, which include load, load must always be async. Create on the other hand can be synchronous, and that is what is enabled here. This matches how dds work.

We can't split the sync part and the async part here. the whole things need to be sync, as we need a net new datastore synchronously that ready to be used, and have its handle stores in the same js turn, to not break on user input.

I see, thank you - that makes more sense.

adding a new type is the most compatible thing according to our type tests, as it typescript has trouble with inference over typed arrays. not sure what to call this, everything else feels quite verbose, so kind of happy with just adding 2

i basically rewrote this test to split the parent and child datastore, and handle more cases, so i'd recommend split view, to really just review the latest.